home *** CD-ROM | disk | FTP | other *** search
- ======================================================================
- F A Q
- doc: Fri Apr 24 14:58:47 1992
- dlm: Tue Aug 17 16:52:34 1993
- (c) 1992 ant@ips.id.ethz.ch
- uE-Info: 10 57 T 0 0 72 3 2 8 ofnI
- ======================================================================
-
- Q: I get the message ``Warning: stderr is lost!'' in the messages file.
- A: Recompile everything with the NOASYNCIO_QUIRK defined.
-
- Q: When I issue an inetray or an inetray.ping I get a a dot every few
- seconds and the program does not seem to proceed.
- A: There is either another process using the same socket running on your
- machine (another inetray, maybe), or the servers didn't terminate
- normally on your last session. You can check by issuing netstat -f
- inet.
- If there are still workers running on remote machines, you just have
- to wait roughly one minute to give them time to shut down orderly; if
- another program uses the same port, you have to add a resultport:
- definition to your ~/.inetrayrc.
- Note that inetray and inetray.ping will just continue trying on the
- port, printing a dot every few seconds until the problem disappears
- (which eventually will).
-
- Q: Why does inetray need so much more memory than rayshade?
- A: There are several reasons for this:
- a) The dispatcher needs a lot of memory since it has to buffer a
- whole frame. Rayshade does not have to buffer a whole frame since
- it renders strictly sequentially.
- b) The dispatcher furthermore reads the input file and builds up the
- geometry data. This feature allows printing of the error and
- warning messages before the rendering actually starts (and cloggs
- the syslogs on the worker machines). The memory could and should
- be freed after checking the input before allocating the frame
- buffer but this is not done at the moment.
- c) On every worker machine the inputfile is read and geometry built
- up for every used CPU - if you use more than one CPU you need more
- memory. This simplifies the handling of multiple CPUs greatly:
- every CPU can be viewed as simply another machine. No special code
- is required.
- d) The actual work is handled by a forked process. This process is a
- copy of the server process and contains all geometry data.
- Therefore, 2 copies of all data exist for each CPU used. This
- solution is quite ugly in terms of memory but very nice in terms
- of simplicity. Without forking a new process, process controls
- (basically sending remote signals) would be very hard if at all
- possible without changing the rayshade source. The parent must
- keep the memory because it will fork further workers later on.
-
- Q: I don't seem to be able to ignore a host from my ~/.inetrayrc file.
- A: add ignore: name, where name is the exact(!) string as printed by
- inetray.ping.
-
- Q: I had problems in the last session and now there seem to still be
- servers/workers running and/or connections open.
- A: Issue an inetray.kill in the same directory where you started the
- problem session. All what's left running after that should kill
- itself after roughly a minute anyway.
-
- Q: I think Inetray is a great program and I want to send loads'a money
- to the author to thank him.
- A: Do so: Andreas Thurnherr, Birkenstr 3, 8640 Rapperswil, Switzerland.
-
- Q: When I trace, workers register correctly but suddenly I get a lot of
- messages about lost connections.
- A: The workers terminated while reading and processing the input-files.
- Check for error messages in your syslog (or in your temp-directory if
- NOASYNCIO_QUIRK is set). Usually the files are not there or not
- accessible for the user under which the servers are running. Note
- that files like /tmp are usually there on every machine but they are
- different even on machines which share there filesystems.
-
-